Automated test equipment (ATE) can be any testing assembly that performs a test on a device, semiconductor wafer or die, etc. ATE assemblies may be used to execute automated tests that quickly perform measurements and generate test results that can then be analyzed. An ATE assembly may be anything from a computer system coupled to a meter, to a complicated automated test assembly that may include a custom, dedicated computer control system and many different test instruments that are capable of automatically testing electronics parts and/or semiconductor. Automatic Test Equipment (ATE) is commonly used within the field of electrical chip manufacturing. ATE systems both reduce the amount of time spent on testing devices to ensure that the device functions as designed and serve as a diagnostic tool to determine the presence of faulty components within a given device before it reaches the consumer.
In testing devices or products, e.g. after production, it is crucial to achieve among others a high product quality, an estimation of the device or product performance, a feedback concerning the manufacturing process and finally a high customer contentment. Usually a plurality of tests is performed in order to ensure the correct function of a device or product. Because the testing process is expensive, in addition to ensuring performance of the devices, it is also important to maximize testing speed and throughput.
A test plan or test program comprises all user-defined data and control flows that are necessary to perform a semiconductor device test on an ATE system. More specifically, a test plan is a program where test conditions which satisfy device specifications, combinations of test conditions and test algorithms, and a test flow are described in the language of the tester software. The main control flow in a test program, which dictates the sequence of individual tests to be applied to the DUTs, and the order in which the tests will be applied (which is dependent on the results of individual tests), is referred to as the test program flow.
When a test program is written for a DUT, in general a predominant part of the program is “data” for device test, and the rest is the program code, which realizes the test methodology itself. The data is DUT-dependent (e.g., power supply conditions, signal voltage conditions, timing conditions, etc.). The test code may consist of methods to load the specified device conditions on to tester hardware, and also those needed to realize the user specified objectives such as data-logging, etc. The ATE framework can also provide a hardware-independent test and tester object model that allows the user to perform the task of DUT test programming.
Since test methodology is a significant component in device test quality and tester productivity, it is often encapsulated from the end users. This separation results in safer operation of the system. Further, to increase the reusability of test code, such code should be independent of any device-specific data, e.g., pin name, stimulus data, etc. or device-test-specific data, e.g., conditions for DC units, measurement pins, number of target pins, name of pattern file, addresses of pattern programs, etc. If code for a test is compiled with data of these types, the reusability of the test code would decrease. Therefore, any device-specific data or device-test-specific data should be made available to the test code externally as inputs during code execution time.
In conventional ATE tester software, a “test class,” realizes the separation of test data and code (and, hence, the reusability of code) for a particular type of test. Such a test class could be regarded as a “template” for separate instances of a test, which differ from each other only on the basis of device-specific and/or device-test-specific data. Test classes are typically specified in the test plan file. Each test class typically implements a specific type of device test or setup for device test. For example, the tester software can provide sample test classes to implement functional tests, AC parametric tests, and DC parametric tests. Accordingly, a test class is the template for a test. Device-dependent test conditions are not described in the test class itself. Only an algorithm for executing tests using the test system is described.
Test classes allow the user to configure class behavior by providing parameters that are used to specify the options for a particular instance of that test. For example, a test class for implementing a functional test may provide parameters to specify a test pattern to execute on the DUTs being tested. Also it may provide parameters to specify the level and timing conditions for the test. Specifying different values for these parameters allows the user to create different instances of the functional test. In one embodiment, test classes are developed in a conventional programming language such as C++.
A tester software system such as Advantest Corporation's T2000 System Software, typically comprises a compiler, which compiles test plans written in the programming language of the tester system, e.g. OPENSTAR Test Programming Language (“OTPL”). OTPL can be used to describe test execution sequence and the corresponding test conditions used. While OTPL can describe a test plan, it typically does not describe any test algorithm. The test algorithm in a system such as T2000, for example, can be described using the C++ language in a test class as discussed above.
Most users of an ATE use a development environment, e.g. Microsoft Developers Studio (“MDS”) to prepare their test classes. Typically, the users will be provided with plug-ins from the developers of the tester software system so they can edit and create test plans within the same environment. Thus, users are able to write out test classes and test plans and carry out debugging from within the development environment of their choice. A development environment such as MDS can typically provide an “Edit and Continue” feature for debugging projects. “Edit and continue” is a time-saving feature that enables a user to make changes to the source code while the program is in break mode. When the execution of the program is resumed by choosing an execution command such as “continue” or “step,” the edit and continue” operation automatically applies the code changes with certain limitations. This allows the user to make changes to the code during a debugging session, instead of having to stop, recompile the entire program, and restart the debugging session.
The “edit and continue” feature available in typical development environments, e.g., MDS, have several limitations, however, that restrict a user's ability to fully take advantage of the feature. First, it cannot be used in connection with all types of code. For example, it cannot be used in a debugging environment when debugging 64-bit code. As a result, many users of tester software that develop 64-bit test classes and test plans for performance reasons are unable to take advantage of this feature.
More importantly, the conventional “edit and continue” feature has various limitations on the type of code changes allowed. For example, one drawback is that conventional development environments only allow relatively minor code changes to be made when using the feature. Typically, the altered code section is recompiled, and a small portion of executing memory corresponding to the altered code is swapped out and replaced with a new block of memory generated using the new code. Thereafter, the appropriate instruction pointers are set accordingly.
The feature, as designed in conventional systems, is not able to handle any intricate code alterations that would require anything more complex than making a minor change in the code, e.g. syntactical changes, which would alter only a relatively small section of loaded memory. As a result, it is not very useful for developers of test classes for ATE. If users make any substantial error in the preparation of the test class or need to replace a test class for any other reason while a test plan is executing, they typically have to stop the test plan and unload it first. Subsequently, the developers need to edit, recompile, and relink the test class. Then, they need to reload the test plan and restart it from the beginning before getting back to the original point in the code. Such a work flow is time-consuming and error-prone.